Process and system for quality assurance for software

ABSTRACT

A process and system for quality assurance. The process includes developing a high level quality assurance resource estimate and a high level quality assurance time estimate; producing a business analysis outline; and creating an acceptance test plan using an acceptance test plan template with the business analysis outline. The process further includes creating a plurality of test cases to be carried out during a test execution phase of the quality assurance process using the acceptance test plan; refining the high level quality assurance resource estimate and the high level quality assurance time estimate based on the acceptance test plan; executing each of the test cases in an acceptance test to produce a set of test results for each of the test cases; and evaluating the test results against the refined high level quality assurance resource estimate and the refined high level quality assurance time estimate. One or more defects tracked during the execution of the test cases are reported and a sign off of the acceptance test is negotiated with a client. An application audit package is created and stored for future reference.

BACKGROUND OF THE INVENTION

[0001] The present invention relates to quality assurance processes usedin software development, and more particularly, to acceptance testingprocesses used in software development.

[0002] Acceptance testing is a quality assurance process that is used inthe software industry for a newly developed software application. It isa process of verifying that the newly developed software applicationperforms in accordance with design specifications for such newlydeveloped software. The goals of acceptance testing are to achieve zerodefects in the newly developed software application and on-time deliveryof such newly-developed software application. Acceptance testing may beperformed for an internally developed software application as well asfor an externally developed software application. Acceptance testing maybe performed for a software application intended for use internallywithin a business entity as well as for a software application developedfor a client. Acceptance testing may be performed by a softwaredeveloper, a user of the software or a third party.

[0003] However, acceptance testing is often performed in an ad hocmanner. Steps in an acceptance testing process may be repeated orinefficiently performed. Thus, acceptance testing may require a greateramount of time than is ideal and may not effectively eliminate defectsin the newly developed software.

BRIEF SUMMARY OF THE INVENTION

[0004] A process and system for quality assurance for a newly developedsoftware application is described. The process includes developing ahigh level quality assurance resource estimate and a high levelquality-assurance time estimate; producing a business analysis outline;and creating an acceptance test plan using an acceptance test plantemplate with the business analysis outline. The process furtherincludes creating a plurality of test cases to be carried out during atest execution phase (i.e., during an acceptance test) of the qualityassurance process using the acceptance test plan; refining the highlevel quality assurance resource estimate and the high level qualityassurance time estimate based on at least the acceptance test plan;executing each of the test cases in an acceptance test to produce a setof test results for each of the test cases; and evaluating each of thesets of test results against the refined high level quality assuranceresource estimate and the refined high level quality assurance timeestimate. One or more defects tracked during the execution of each ofthe test cases are reported and corrected and a sign off of theacceptance test is negotiated with a client. An application auditpackage is created and stored for future reference.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005]FIG. 1 is a flow chart illustrating one embodiment of a process ofconducting an acceptance test;

[0006]FIG. 2 is a flow chart illustrating one embodiment of a process ofconducting a staff allocation;

[0007]FIG. 3 is a flow chart illustrating one embodiment of a process ofdeveloping an acceptance test plan;

[0008]FIG. 4 is a flow chart illustrating one embodiment of a process ofcreating a plurality of test scripts for an acceptance test;

[0009]FIG. 5 is a flow chart illustrating one embodiment of a processfor processing defects in an acceptance test;

[0010]FIG. 6 is an example screen shot of one embodiment of a functionlog document;

[0011]FIG. 7 is an example screen shot of one embodiment of a testscript document;

[0012]FIG. 8 is a block diagram of one embodiment of a system foracceptance testing; and

[0013]FIG. 9 is a block diagram of one embodiment of a system for dataanalysis for acceptance testing.

DETAILED DESCRIPTION OF THE INVENTION

[0014] The present invention is described in relation to a process andsystem for acceptance testing of software. Nonetheless, thecharacteristics and parameters pertaining to the process and system ofthe invention may be applicable to acceptance testing of other types ofproducts and services. The process and system, and the sub-processes andsubsystems, of the invention may be used for updates to existingsoftware applications as well as for newly developed softwareapplications.

[0015] Acceptance testing is a third tier of software functionalityverification. Acceptance testing occurs after a first tier of unittesting and a second tier of system testing with respect to a particularsoftware product or application have been completed. Acceptance testinginvolves testing the entire software application's functionality as itis to be used in a production environment by a user.

[0016]FIG. 1 is a flowchart illustrating one embodiment of a process ofconducting an acceptance test. At step 101, a high level qualityassurance resource estimate and a high level quality assurance timeestimate are developed. At step 102, a business analysis outline isproduced. At step 103, an acceptance test plan is created using anacceptance test plan template with the business analysis outlineproduced at step 102. At step 104, the high level quality assuranceresource estimate and the high level quality assurance time estimate arerefined. At step 105, a plurality of test cases to be carried out duringa test execution phase of an acceptance test are developed. At step 106,each of the test cases are executed in the acceptance test to produce aset of test results for each of the test cases. At step 107, each of thesets of results of the test cases is evaluated against predicted resultsoutlined in an acceptance test function log or test scripts, describedbelow with reference to step 312 of FIG. 3. At step 108, one or moredefects tracked during the execution of each of the test cases areprocessed. At step 109, a sign-off of the acceptance test is negotiatedwith a client. At step 110, an application audit package is created andstored for future reference.

[0017] As will be described in more detail below, the various processesillustrated in FIG. 1 may be performed by a system, such as the systemillustrated in FIGS. 8 and 9. Additionally, the sequence of steps shownin FIG. 1 may be modified in accordance with the present invention. Thesteps illustrated in FIG. I will now be described in greater detail.

[0018] At step 101, a high level quality assurance resource estimate anda high level quality assurance time estimate is developed. Each of theseestimates may be based on a past quality assurance experience, a numberof test cases and/or a level of staffing. The high level qualityassurance resource estimate and the high level quality assurance timeestimate may each be developed in a staff allocation process, asdescribed below.

[0019] The high level quality assurance resource estimate and the highlevel quality assurance time estimate are each developed very early in aproject life cycle of a software development project. Thus, theacceptance testing process is also started early in the life cycle ofthe software development project. Early initiation of the acceptancetesting process allows earlier detection and correction of any defects,and a lowering of a cost of correction of any defects.

[0020] At step 102, a business analysis outline is produced. Thebusiness analysis outline is an input document to the acceptance testingprocess. The business analysis outline may be prepared by a lead qualityassurance analyst. The business analysis outline may include, forexample, an interpretation of a plurality of user requirements for asoftware application to be developed in the software developmentproject. The business analysis outline, may also include a plurality ofqueries for making a determination of whether the user requirements havebeen met. The step 102 of producing the business analysis outline alsoprovides an opportunity to reevaluate and confirm that the prior highlevel quality assurance resource estimate and the high level qualityassurance time estimate are correct.

[0021] At step 103, an acceptance test plan for testing the softwareapplication is created. The acceptance test plan may be created by thelead quality assurance analyst using an acceptance test plan templatealong with the business analysis outline developed at step 102. Theacceptance test plan is a document describing a plurality of steps to beconducted during execution of the acceptance test, a plurality offactors that need to be considered in executing the acceptance test, andany other elements associated with the execution of the acceptance test.The acceptance test plan creation process will be described in moredetail below with reference to FIG. 3.

[0022] At step 104, the prior high level quality assurance resourceestimate and the high level quality assurance time estimate are refined.The high level quality assurance resource estimate and the high levelquality assurance time estimate may be refined based on the acceptancetest plan created at step 103.

[0023] At step 105, a plurality of test cases or “function logs” aredeveloped using the acceptance test plan created in step 103. The testcases or function logs are comprised of a plurality of detaileddescriptions of tests that are to be carried out during the execution ofthe acceptance test plan. The development of the test cases will bedescribed in more detail below with reference to FIG. 4.

[0024] At step 106, each of the test cases developed in step 105 areexecuted in the acceptance test. At step 107, a set of test results fromeach of the executed test cases is evaluated. Each of the sets of testresults is evaluated against a set of predefined expected results. Eachof the test cases is then labeled by a tester to indicate a “pass” or a“fail”. Each of the test cases that fails may indicate a defect in thesoftware application.

[0025] At step 108, each of the defects reported during the executionstep 106 and the evaluation step 107 of the acceptance test arereported. At step 108, as a defect is encountered, the defect isidentified, logged and submitted to the team of software developers forcorrection. The team of software developers may correct each of theidentified defects or explain why the identified corrected defect is nota defect. Once corrected, each of the identified corrected defects isretested, and if appropriate, closed.

[0026] At step 109, a sign-off of the acceptance test is negotiated witha client. The lead quality assurance analyst may initiate a discussionwith the client to review test results. At this time, any outstandingissues (open defects, system or training issues) may be negotiated. Forexample, the effect of defects on time frames may be discussed with theclient. In some cases, open defects have too great an impact on systemfunctionality and, thus, implementation may need to be moved forwarduntil the defect is fixed. In other cases, open defects are minor enoughthat implementation is undisturbed and the application is moved intoproduction with the known defects.

[0027] At step 110, an application audit package is created and storedfor future reference. The application audit package may includecompleted function logs, a project defect log, a sample of a few defecttickets and resolutions, a representative sample of products producedand a business area sign-off form. The application audit package mayalso include, where applicable, an acceptance test plan, a finalbusiness analysis, and a service request.

[0028] The acceptance test process of the present invention provides arepeatable process that effectively directs a verification of a softwaredevelopment process and efficiently eliminates any defects found. Theacceptance testing process communicates a plurality of roles andresponsibilities for each person involved in the acceptance testingprocess and a methodology required to successfully validatefunctionality of a newly developed software application. The acceptancetesting process facilitates communication between a client, a team ofdevelopers, a tester and an end user, thereby removing any deviationsbetween the software application as specified by the client and thesoftware application delivered to the client by the team of developers.

[0029] The acceptance testing process of the invention also eliminatesredundant steps involved in prior acceptance testing processes and is,therefore, more efficient. The acceptance testing process is easy toexecute and impart to others, including less-experienced, non-technicalemployees who may need to be trained in conducting the acceptancetesting process. The acceptance testing process also facilitates meetingone or more milestones in a software development project.

[0030]FIG. 2 is a flowchart illustrating one embodiment of a process forconducting a staff allocation. The staff allocation process involvesthree (3) stages of making quality assurance resource estimates andquality assurance time estimates. At step 201, a high level qualityassurance resource estimate and a high level quality assurance timeestimate are developed. At step 202, the high level quality assuranceresource estimate and the high level quality assurance time estimate arerecorded in a staff allocation document. At step 203, the high levelquality assurance resource estimate and high level quality assurancetime estimate are both confirmed. At step 204, the high level qualityassurance resource estimate and the high level quality assurance timeestimate are both refined.

[0031] At step 201, the high level quality assurance resource estimateand the high level quality assurance time estimate are developed fromthe business analysis outline. The high level quality assurance resourceestimate and the high level quality assurance time estimate developed instep 201 are the same as the high level quality assurance resourceestimate and the high level quality assurance time estimate developed instep 101 of FIG. 1.

[0032] Three (3)processes are used in making the estimates. The firstprocess is a “similar project approach.” In the similar projectapproach, a high level quality assurance time estimate and a high levelquality assurance resource estimate are derived from a quality assuranceresource estimate and a quality assurance time estimate from a similarlycomplex and similarly sized prior development project. The secondprocess is a “building block approach.” In the building block approach,a number of test cases are estimated and that number of test cases ismultiplied by a time estimated to execute the test cases. The thirdprocess is a “resource leveling, approach.” In the resource levelingapproach, resources are added to those that were used in a priordevelopment project to reduce an implementation time that was requiredfor implementing the prior development project.

[0033] At step 202, the high level quality assurance resource estimateand the high level quality assurance time estimate are recorded in thestaff allocation document. At step 203, the high level quality assuranceresource estimate and the high level quality assurance time estimate inthe staff allocation document developed in step 202 are confirmed. Thehigh level quality assurance resource estimate and the high levelquality assurance time estimate are confirmed during the review of thebusiness analysis outline process described above with reference to step102 in FIG. 1.

[0034] At step 204, the high level quality assurance resource estimateand the high level quality assurance time estimate are refined. The highlevel quality assurance resource estimate and the high level qualityassurance time estimate are refined in step 204 based on an acceptancetest plan, such as the acceptance test plan created in step 103 of FIG.1 above. The processes described with reference to FIG. 2 may beperformed by a system, such as the system described below with referenceto FIGS. 8 and 9.

[0035] A plurality of inputs to the staff allocation process may includea past quality assurance project data, the business analysis outline andthe acceptance test plan. The output of the staff allocation processincludes the high level quality assurance time estimate and the highlevel quality assurance resource estimate, and a staff allocationdocument which may be provided to members of interested or associatedgroups including, for example, information technology group. Eachsuccessive stage of the quality assurance staff allocation processrequires more accurate time and resource predictions.

[0036]FIG. 3 is a flowchart illustrating one embodiment of a process ofdeveloping an acceptance test plan. At step 301, an overview is createdfor the acceptance test plan process. At step 302, a plurality ofobjectives for completing the acceptance test plan are developed. Atstep 303, a plurality of risks associated with the acceptance testingare identified. At step 304, a plurality of remedies for the identifiedrisks are proposed. At step 305, a plurality of assumptions for a systemenvironment for conducting the acceptance testing is identified. At step307, a plurality of limitations imposed upon the acceptance test areidentified. At step 308, a plurality of sign-offs required for approvingthe acceptance test plan are identified. At step 309, a glossary ofterms used in the acceptance test plan is drafted. At step 310, astrategy and an approach for the acceptance test are developed. At step311, a plurality of conditions for execution of the acceptance test planare identified. At step 312, a test specification is created. At step313, the results of the acceptance test plan process are recorded in anacceptance test plan document. The process illustrated in FIG. 3 may beperformed by a system, such as the system illustrated in FIGS. 8 and 9.

[0037] Describing the process illustrated in FIG. 3 in more detail, atstep 301, an overview of the software application being developed iscreated. The overview comprises a brief description of the softwareapplication being developed. For example, if the software applicationbeing developed is for a web-site, the overview may include adescription of the web-site and a plurality of objectives of thesoftware application.

[0038] At step 302, a plurality of objectives for the acceptance testplan are developed. The objectives may comprise a plurality ofhigh-level goals and a plurality of strategies required to successfullycomplete the acceptance test. The objectives may comprise ensuring thata functionality for the software application being developed as outlinedin the acceptance test plan has been successfully tested, verifying thatthe objectives of the software application being tested have beensuccessfully met and verifying that the software application beingtested can coexist with all required functionality. Additionally, theobjectives may include verifying through regression testing that otherinstalled or related software applications continue to properlyfunction, detailing a plurality of activities required to prepare andconduct acceptance testing, defining a methodology that will be used totest and verify system functionality and using acceptance testing as aneffective communication tool in identifying and resolving a plurality ofsystem issues and problems. The objectives may further includedetermining and coordinating a plurality of responsibilities for personsinvolved in the acceptance testing, defining a plurality of environmentsand test cycle approaches required to effectively complete theacceptance testing and defining all system functions to be tested, aswell as those functions that will not be tested.

[0039] At step 303, a plurality of risks to the acceptance testingprocess are identified. The risks may include risks to a schedule and/orrisks to a quality level. The risks identified may include a tightschedule where any additional functionality or requirement changes couldresult in a delay in implementation of the software application and aneed for dedicated technical support in order to eliminate any testingdown time.

[0040] At step 304, a plurality of remedies or contingencies areproposed for the identified risks. Each identified risk must have acorresponding remedy or contingency. For example, if a risk to anacceptance test schedule is that the schedule is very tight and anyadditional functionality or requirement changes could result in a delayin implementation of the software application, a correspondingcontingency may be that any requirement changes after a certain datemust follow one or more procedures, such as a predetermined changecontrol procedure.

[0041] At step 305, a plurality of assumptions are identified for theacceptance testing. The assumptions may include a plurality of basictesting related issues that are required for a successful acceptancetesting process. For example, the assumptions may include an assumptionthat, at the end of a design phase, a detailed schedule of the softwaredeliverables will be published, all functionality required to fullysupport an application must be ready for acceptance testing on or beforea certain date, and all documentation relating to the softwareapplication will be made available to a quality assurance group on orbefore a certain date.

[0042] At step 306, a system environment for acceptance testing isdescribed. The description of the system environment may include adescription of a hardware and a software interface needed for acceptancetesting. The description may also include a type of hardware andsoftware platform, such as, for example, a specific mainframe system andrelated software interfaces for a Marketing Sales System such as, forexample, Choicepoint™, Correspondence™, EPS™ Electronic Publishing, Code1™, POLK™, Ratabase 1.5™, or other similar systems.

[0043] At step 307, one or more limitations or constraints to theacceptance test plan are identified. The limitations may include, forexample, that the scheduled implementation date for a new softwareapplication is firm and cannot be changed.

[0044] At step 308, a plurality of sign-offs required for approving theacceptance test plan are identified. The sign-offs required may includea list of persons from a client area who will be responsible forapproving the acceptance test plan and reviewing any test material and alist of persons from the information technology group who will approvethe acceptance test plan from a technical point of view.

[0045] At step 309, a glossary of terms used in the acceptance test planis drafted. The glossary of terms may include a definition of eachtechnical, business, and quality assurance term that may be unfamiliarto those reviewing the acceptance test plan. The glossary of terms mayinclude, for example, a name of the software application being tested, avendor name, and other terms and acronyms that may be unfamiliar to aperson reviewing the acceptance test plan.

[0046] At step 310, a strategy is developed for the acceptance testing.The strategy or approach for the acceptance testing includes identifyinga test environment for the execution of the acceptance test plan anddeveloping a scope and an approach for the execution of the acceptancetest plan.

[0047] Identifying the test environment comprises providing a high leveldescription of resources, both hardware and software, that will berequired in order to conduct the acceptance testing. For example, thedescription of the test environment may include a requirement for afacility to be available at a certain time, including evening andweekend availability, an identification of all interfaces that must beavailable to verify the test cases, and an identification of allfunctionality of the software being tested that must be ready foracceptance testing on a certain date for the start of acceptancetesting.

[0048] The scope and approach for the acceptance testing comprises anidentification of one or more functions or tests that are planned forthe acceptance testing and any testing limitations or identifiableranges of the tests. The scope and approach may include, for example, anumber of stages of a test with an identification of a type of test. Forexample, the test may include two stages with the first stage comprisinga timing test, if a goal of the software application under developmentis to reduce processing time, and a second stage comprising a systemfunctionality test. The scope and approach of the acceptance testing maythen be further described by listing an approach, such as, for example,“a timing test goal”, “a timing test measurement”, “a timing testspecific form” and “one or more timing test participants and locations”under the timing test state, and “one or more screen flows/links”, “apre-fill validation”, and “one or more default field values”, under thesystem functionality test stage.

[0049] At step 311, one or more conditions required for execution of theacceptance test plan are identified. The conditions may include anentrance criteria condition, a resources required condition, anacceptance test tools condition, and an organization for testingcondition.

[0050] The entrance criteria are one or more events required by thequality assurance group to be successfully completed prior to thebeginning of the acceptance testing. For example, the entrance criteriamay include that a volunteer tester must have an ability to access theacceptance testing site from his home, that an identification of allproblems detected during system testing must be forwarded to the qualityassurance group prior to the start of acceptance testing, a verificationthat the acceptance testing environment is ready to support acceptancetesting, that a test team has been identified and trained, that allsystem documentation has been turned over to the quality assurancegroup, that an acceptance testing schedule has been agreed upon andpublished and that all major interfaces of the software application tobe tested are available for acceptance testing.

[0051] The resources required comprise an identification of the human,hardware and software resources required to complete the acceptancetesting. For example, the identification of the human resources requiredmay include a listing of persons required to conduct the acceptancetesting such as a number of quality assurance analysts required, and anumber of volunteer testers working from home or at the acceptancetesting facility. The identification of the hardware/software resourcesrequired may include an identification of a type of platform such as amainframe system, or Internet access.

[0052] The acceptance test tools include any software package thatautomates any part of the acceptance testing process. For example, theacceptance test tools may include Microsoft Word® or other wordprocessing program, a copy tool for the software application beingtested or a session open tool.

[0053] The identification of the organization for acceptance testingcomprises identification of persons required to conduct the acceptancetesting and their corresponding responsibilities during the acceptancetesting. For example, the responsibilities may include a responsibilityfor “Review of Acceptance Test Plan”, a responsibility for “Keying TestCases”, and a responsibility for “Reviewing Test Results”. Then, thehuman resources required to fulfill such responsibilities may be listedunder each responsibility, such as, for example, in the “Review ofAcceptance Test Plan” category, the human resources required may includea Project Manager, an Applications Team Leader, a Business Analyst, aQuality Assurance and a Business Partner.

[0054] At step 312, a test specification is created for the acceptancetest plan. The test specification may include a teststructure/organization section, a test functions or cases section, atest scripts or function logs section, and a test schedules and testcompletion criteria section. The test structure/organization section maybe comprised of one or two paragraphs relating to one or more types ofprocessing cycles and environment changes that may be needed during theacceptance testing.

[0055] The test functions or cases section makes up the primary sectionof the acceptance test plan. The test functions/cases section identifiesall of the functions or cases to be verified during the acceptancetesting. The test scripts/function logs section should be included inthe test specification so that the function logs and test scripts aregenerally available upon request. A test schedule identifies a scheduleestablished in the scope and approach section of the acceptance testplan.

[0056] The test completion criteria include a paragraph that describes aframework for handling any severe system problems that remain open atthe end of acceptance testing. For example, the test completion criteriamay state that all major functions and sub-functions of the softwareapplication being tested will be considered to have passed acceptancetesting when no severe system problem remains open. The test completioncriteria may then describe how to identify a severe system problem.

[0057] At step 313, the acceptance test plan processes are recorded inan acceptance test plan document. Thus, all of the processes describedfrom step 301 to step 312 will be recorded in a document to be approvedby the persons identified at step 308.

[0058]FIG. 4 is a flowchart illustrating one embodiment of a process ofcreating a plurality of test scripts for an acceptance test plan. Atstep 401, an acceptance test plan is reviewed. Specifically, the testfunctions/cases section of the test specification created at step 312 ofFIG. 3 is reviewed.

[0059] At step 402, a function log process is performed. In the functionlog process, the functions/cases section of the acceptance test plan isreferenced in order to create one or more function logs. A function logmay contain many individual test cases or scenarios. A function log mayinclude a plurality of headings including, a function heading, afunction number heading, an identifier heading, an expected resultsheading and a pass/fail heading. An example of a function log isdescribed with reference to FIG. 6 below. An input to the function logprocess is the test function/cases section of the acceptance test plan.An output of the function log process is a physical document called afunction log.

[0060] At step 403, a test script is created using the function log. Atest script may contain more specific testing instructions than afunction log. The test script may include a plurality of headingsincluding a function/script heading, a function/script number heading, ascript activity per cycle heading, an expected results heading and apass/fail per cycle heading. Either the function logs or the testscripts may be used as guides for executing the acceptance test plan,depending upon the skill level of the tester. If the skill level of thetester is high or if the tester has a lot of experience in conductingacceptance testing, the function logs may be used by the tester.However, if the test scripts are used, a tester having a lower skilllevel may execute the acceptance test. The input to the test scriptprocess is the function log document and the output to the test scriptprocess is the test script document. The test case descriptions from theacceptance test plan, the function logs or the test scripts may be usedas instructions for carrying out test cases, where the test scriptscomprise more detailed instructions than the function logs, and thefunction logs comprise more detailed instructions than the test casedescriptions.

[0061]FIG. 5 is a flowchart illustrating one embodiment of a process ofprocessing defects in an acceptance test plan. At step 501, a potentialdefect is identified during the acceptance testing. At step 502, adefect ticket record is created for the identified potential defect. Atstep 503, the defect is recorded on a project defect tracking log. Atstep 504, the defect ticket record is transmitted to a developer area510. Steps 511-513 occur in developer area 510. At step 511, a developerreviews the defect ticket record. At step 512, the developer correctsthe defect or explains why the identified problem is not a defect. Thedeveloper then updates the defect ticket record to reflect a date ofcorrection of the defect and an identity of a corrector of the defect ifthe defect was corrected. If the identified defect was not corrected,the developer updates the defect ticket record with an explanation forwhy the defect was not corrected. At step 513, the developer returns thedefect ticket record to a quality assurance area. At step 505, a qualityassurance analyst in the quality assurance area checks to see if thedefect needs to be retested. If the defect was corrected in thedeveloper area 510, then the corrected defect will require retesting. Ifthe defect was retested, then, at step 506, the quality assuranceanalyst checks to see if the corrected defect passed the retesting. Ifthe corrected defect did not pass the retesting, the process returns tostep 503 where the updated defect information is recorded on the projectdefect tracking log and transmitted at step 504 to the developer area510. If the corrected defect passes the retesting, the project defecttracking log is updated at step 507 and the defect ticket record is alsoupdated to reflect that the corrected defect passed the retesting andthat the defect ticket record is closed. If the defect does not need tobe retested, the project defect tracking log is updated at step 507. Atstep 508, the defect ticket records are placed in a project folder.

[0062] The defect ticket record of step 502 may include anidentification of the project, a defect number, a priority levelidentification, an identification of a person reporting the defect, atest case number, a function area identification, a description of thedefect, a date of opening of the defect ticket, an identification of thesoftware application subject to the defect, an identification of acorrector and a date of correction of the defect, an identification of aretester and a date of retesting, and a date of closing of the defectticket record if the corrected defect passes the retesting.

[0063]FIG. 6 is an example of a screen shot of one embodiment of afunction log document 600 illustrating an acceptance test plan for anautomotive insurance software application developed for an automotiveinsurance provider entity. It should be understood, however, that thefunction log document of the invention can be modified as required foruse by any type of business entity for acceptance testing of any type ofsoftware application.

[0064] Function log document 600 includes a plurality of fieldsincluding a Function field 601, a Function Number field 602, anIdentification Number field 603, an Expected Results field 604 and aPass/Fail field 605. During an acceptance test, a plurality of testcases 606-610 are performed. With reference to a test case 606, the testcase 606 is for a user who learned of the insurance provider through aradio commercial, who has one car with one operator where the user has adate of birth in 1930 and the car has an annual mileage of 3,000 milesper year, as listed in Function field 601 of test case 606. A functionnumber assigned this test case 606 is 1, as listed under the FunctionNumber field 602. The test case 606 is assigned an identification numberof 840430090 as listed in the Identification Number field 603. Theexpected results of the entered information for the test case 606 isthat the user should not be asked for the odometer purchase date or dateof purchase, as listed under the Expected Results field 604. Anindication is listed in the Pass/Fail field 605 of whether the test case606 passed or failed the testing. As shown in FIG. 6, the test case 606passed the testing.

[0065]FIG. 7 is an example of a screen shot of one embodiment of a testscript document 700. As shown in FIG. 7, the test script document 700 isa test script used for acceptance testing of the automotive insurancesoftware application for insurance requirements in the State ofCalifornia. The test script document 700 includes a plurality of fieldsincluding a Test Case Number field 701, a Log/Script Activity field 702,a User Number field 703, an Expected Results field 704 and a Commentsfield 705.

[0066] The Test Case Number field 701 lists the number of the test case.The log/script activity field 702 lists a user ID and a password to beentered by a tester and detailed instructions on how to perform the testcase. As an illustrative example, a test case 706 is input for asituation where a user lives in California compared to where the userlives in a state other than California. The expected results, as listedin the Expected Results field 704, are that a quote for a cost of anautomotive insurance product should be the same for the user regardlessof whether the user's information was entered into system “Q” or “M”. Asshown in the Comments field 705, the software application subject totesting passed the testing. The Comments field 705 may also be used by atester to enter any comments or notes that indicate some activity needsto be performed or investigated.

[0067]FIG. 8 is a block diagram of a system 800 used for acceptancetesting. System 800 includes a staff allocation module 801, anacceptance test plan module 802, a test script module 803, a defectsprocessing module 804, an external processes module 805 and anacceptance testing module 810. The acceptance testing module 810receives inputs from the staff allocation module 801, the acceptancetest plan module 802, the test script module 803, the defects reportingmodule 804 and the external processes module 805. The execution of theacceptance test plan occurs in the acceptance testing module 810.

[0068] The high level quality assurance resource estimate and the highlevel quality assurance time estimate for the acceptance testing and thestaff allocation module document are developed in the staff allocationmodule 801. The staff allocation module 801 includes means (not shown)for developing the high level quality assurance resource estimate andthe high level quality assurance time estimate and for recording suchhigh level quality assurance resource estimate and high level qualityassurance time estimate in the staff allocation document.

[0069] The acceptance test plan module 802 receives an output from thestaff allocation module 801 and develops an acceptance test plan. Theacceptance test plan module 802 includes means (not shown) fordeveloping the acceptance test plan as described above with reference toFIG. 3.

[0070] The outputs of the acceptance test plan module 802 are coupled tothe acceptance testing module 810 and the test script module 803. Thetest script module 803 receives the acceptance test plan from acceptancetest plan module 802 and generates both the function log document andthe test scripts. The test script module 803 includes means (not shown)for creating the function logs document and the test scripts asdescribed above with reference to FIG. 4. The function logs document andthe test scripts are transmitted to the acceptance testing module 810for execution of the acceptance test plan.

[0071] The defects reporting module 804 receives inputs from both theexternal processes module 805 and the acceptance testing module 810. Thedefects reporting module 804 processes any defects identified during theexecution of the acceptance test plan and transmits the identifieddefects to the developer area. The defects reporting module 804 includesmeans (not shown) for processing defects as described above withreference to FIG. 5.

[0072] The external processes module 805 receives inputs from both theacceptance testing module 810 and the defects reporting module 804. Theexternal processes module 805 has an output connected to the staffallocation module 801. The external processes module 805 includes thedevelopment area, an information technology area, or an area for anyother processes external to the acceptance testing. The externalprocesses module 805 receives or generates a business analysis outlinewhich it transmits to the staff allocation module 801 and the acceptancetesting module 810.

[0073]FIG. 9 is a block diagram illustrating the components of oneembodiment of a system 900 used for acceptance testing. As shown in FIG.9, system 900 may be comprised of a processor module 902, a display 904,a user input 906, a data input module 908, a data storage module 910,and an output module 912. Generally, the processor module 902 receivesinputs from the data input module 908 and the user input module 906, andprovides outputs via the display 904 and the output module 912. Theprocessor module 902 may also receive inputs and provide outputs throughthe data storage module 910.

[0074] According to an embodiment of the invention, the processor module902 may be a standard processor suitable for performing any necessarycalculations required for the acceptance testing, including multipletask processing as necessary. As illustrated, the processor module 902may receive inputs from the data input module 908 and the user inputmodule 906, as well as data from the data storage module 910. The datainput module 908 may be any conventional data input device, such as amagnetic or an optical disk drive, a CD-ROM, a scanner, a modem, anInternet connection, a hard-wired connection, or any other device forinputting data to the processor module 902. The user input module 906may be any conventional user input device, such as a keyboard, atouch-screen, a roller-ball, a mouse, a pointer, or any other device fora user to enter and direct manipulation of data in the processor module902.

[0075] The data storage module 910 may be comprised of any conventionalstorage device, such as a computer memory, a magnetic or an optical discor a CD-ROM, a tape-to-tape reel, or any other device for storing data.In the context of conducting the acceptance testing, the data storagemodule 902 may contain information related to the business analysisoutline, the acceptance test plan, the high level quality assurance timeestimate and the high level quality assurance resource estimate, thepast quality assurance project, defects and other information. Theprocessor module 902 may be capable of accessing data in the datastorage module 910. Thus, according to an embodiment of the invention,the data storage module 910 may be searchable by a field or in a varietyof other conventional manners.

[0076] As illustrated, the processor module 902 may provide informationthrough the display 904 and the output module 912, as well as providedata to the data storage module 910. The display 904 may be anyconventional display device, such as a television, a monitor, or anyother display device. The output module is 912 may be any conventionaloutput device, such as a printer, a facsimile machine, a magnetic discdrive, a compact disc drive or an optical disc drive, a modem, anInternet connection, a hard-wired connection, or any other device foroutputting data to the processor module 902.

[0077] While the foregoing description includes many details andspecificities, it should be understood that these have been included forpurposes of explanation only, and are not to be interpreted aslimitations of the present invention. Many modifications to theembodiments described above can be made without departing from thespirit and scope of the invention, as is intended to be encompassed bythe following claims and their legal equivalents.

What is claimed is:
 1. A process of conducting quality assurancecomprising the steps of: (a) developing a high level quality assuranceresource estimate and a high level quality assurance time estimate; (b)producing a business analysis outline; (c) creating an acceptance testplan using an acceptance test plan template with the business analysisoutline; (d) refining the high level quality assurance resource estimateand the high level quality assurance time estimate based on at least theacceptance test plan; (e) creating a plurality of test cases to becarried out during a test execution phase of the quality assuranceprocess using the acceptance test plan; (f) executing each of the testcases in an acceptance test to produce a set of test results for each ofthe test cases; (g) evaluating each of the sets of the test resultsagainst a set of the refined high level quality assurance resourceestimate and the refined high level quality assurance time estimate; (h)reporting one or more defects tracked during the execution of each ofthe test cases; (i) correcting the one or more reported defects; (j)re-testing the corrected one or more defects; (k) negotiating a sign offof the acceptance test with a client; and (l) creating and storing anapplication audit package.
 2. The process of claim 1 wherein the step ofdeveloping the high level quality assurance resource estimate and thehigh level quality assurance time estimate comprises a sub-step ofdeveloping the high level quality assurance resource estimate and thehigh level quality assurance time estimate based on a similar projectestimate.
 3. The process of claim 1 wherein the step of developing thehigh level quality assurance resource estimate and the high levelquality assurance time estimate comprises a sub-step of adding resourcesto a past quality assurance experience to reduce an implementation time.4. The process of claim 1 wherein the step of developing the high levelquality assurance resource estimate and the high level quality assurancetime estimate comprises a sub-step of estimating a number of test casesand multiplying the estimated number of test cases by an average timeestimated to execute each of the test cases.
 5. The process of claim 1further comprising a step of attending one or more project meetings ifthe meetings are of specific value to one or more project testing goals.6. The process of claim 1 wherein the step of refining the high levelquality assurance resource estimate and the high level quality assurancetime estimate further comprises a step of refining the high levelquality assurance resource estimate and the high level quality assurancetime estimate based on the business analysis outline.
 7. The process ofclaim 1 wherein the step of refining the high level quality assuranceresource estimate and the high level quality assurance time estimatefurther comprises a step of refining the high level quality assuranceresource estimate and the high level quality assurance time estimatebased on past quality assurance project data.
 8. The process of claim 1wherein the step of developing the high level quality assurance resourceestimate and the high level quality assurance time estimate furthercomprises a step of producing a staff allocation document and the stepof refining the high level quality assurance resource estimate and thehigh level quality assurance time estimate comprises the sub-step ofrefining the staff allocation document.
 9. The process of claim 1wherein the quality assurance process is an acceptance test process. 10.The process of claim 1 wherein the quality assurance process is asoftware development acceptance test process.
 11. The process of claim 1wherein the step of creating the test cases comprises a sub-step ofcreating a plurality of test scripts and the step of executing the testcases comprises a sub-step of executing each of the test scripts.
 12. Asystem for conducting a quality assurance process comprising: (a) meansfor developing a high level quality assurance resource estimate and ahigh level quality assurance time estimate; (b) means for producing abusiness analysis outline; (c) means for creating an acceptance testplan using an acceptance test plan template with the business analysisoutline; (d) means for refining the high level quality assuranceresource estimate and the high level quality assurance time estimatebased on at least the acceptance test plan; (e) means for creating aplurality of test cases to be carried out during a test execution phaseof the quality assurance process using the acceptance test plan; (f)means for executing each of the test cases in an acceptance test toproduce a set of test results for each of the test cases; (g) means forevaluating each of the sets of test results against the refined highlevel quality assurance resource estimate and the refined high levelquality assurance time estimate; (h) means for reporting one or moredefects tracked during the execution of each of the test cases; (i)means for correcting the one or more reported defects; (j) means forre-testing the corrected one or more defects; (k) means for negotiatinga sign off of the acceptance test with a client; and (l) means forcreating and storing an application audit package.
 13. The system ofclaim 12 wherein each of the high level quality assurance resourceestimate and the high level quality assurance time estimate is based ona similar project estimate.
 14. The system of claim 12 wherein each ofthe high level quality assurance resource estimate and the high levelquality assurance time estimate is based on adding resources to a pastquality assurance experience to reduce an implementation time.
 15. Thesystem of claim 12 wherein each of the high level quality assuranceresource estimate and the high level quality assurance time estimate isbased on estimating a number of test cases and multiplying the estimatednumber of test cases by an average time estimated to execute each of thetest cases.
 16. The system of claim 12 further comprising means forattending one or more project meetings if the one or more projectmeetings are of specific value to one or more project testing goals. 17.The system of claim 12 wherein the means for refining the high levelquality assurance resource estimate and the high level quality assurancetime estimate further comprises means for refining the high levelquality assurance resource estimate and the high level quality assurancetime estimate based on the business analysis outline.
 18. The system ofclaim 12 wherein the means for refining the high level quality assuranceresource estimate and the high level quality assurance time estimatefurther comprises means for refining the high level quality assuranceresource estimate and the high level quality assurance time estimatebased on past quality assurance project data.
 19. The system of claim 12wherein the means for developing the high level quality assuranceresource estimate and the high level quality assurance time estimatefurther comprises means for producing a staff allocation document andwherein the means for refining the high level quality assurance resourceestimate and the high level quality assurance time estimate includesmeans for refining the staff allocation document.
 20. The system ofclaim 12 wherein the quality assurance process is an acceptance testprocess.
 21. The system of claim 12 wherein the quality assuranceprocess is a software development acceptance test process.
 22. Thesystem of claim 12 wherein the means for creating the test casesincludes means for creating a plurality of test scripts and wherein themeans for executing each of the test cases includes means for executingeach of the test scripts.
 23. A process of conducting a staff allocationin a quality assurance process comprising the steps of: developing ahigh level quality assurance resource estimate and a high level qualityassurance time estimate using a business analysis document; andrecording the high level quality assurance resource estimate and thehigh level quality assurance time estimate in a staff allocation moduledocument.
 24. The process of claim 23 wherein the high level qualityassurance is resource estimate and the high level quality assurance timeestimate is based on a similar project estimate.
 25. The process ofclaim 23 wherein the high level quality assurance resource estimate andthe high level quality assurance time estimate is based on addingresources to a past quality assurance experience to reduce animplementation time.
 26. The process of claim 23 wherein the high levelquality assurance resource estimate and the high level quality assurancetime estimate is based on estimating a number of test cases andmultiplying the estimated number of test cases by an average timeestimated to execute each of the test cases.
 27. The process of claim 23wherein the step of developing the high level quality assurance resourceestimate and the high level quality assurance time estimate furthercomprises a sub-step of using a past quality assurance projectacceptance test plan and data.
 28. The process of claim 23 furthercomprising a step of confirming the high level quality assuranceresource estimate and the high level quality assurance time estimate byreviewing the business analysis document, creating one or morestatements, and verifying the one or more statements.
 29. The process ofclaim 23 further comprising a step of refining the high level qualityassurance resource estimate and the high level quality assurance timeestimate by listing a project by one or more functions, creating aplurality of statements, verifying the statements, confirming the highlevel quality assurance resource estimate and the high level qualityassurance time estimate, and identifying a plurality of acceptance testcharacteristics.
 30. The process of claim 29 wherein the acceptance testcharacteristics include a number of functions, a number of test cases, anumber of remaining test cases, a number of defects, a number of opendefects, a responsible party and a status.
 31. The process of claim 23wherein the quality assurance process is a software development process.32. A system for conducting a staff allocation in a quality assuranceprocess comprising: means for developing a high level quality assuranceresource estimate and a high level quality assurance time estimate usinga business analysis document; and means for recording the high levelquality assurance resource estimate and the high level quality assurancetime estimate in a staff allocation module document.
 33. The system ofclaim 32 wherein the means for developing the high level qualityassurance resource estimate and the high level quality assurance timeestimate comprises means for developing the high level quality assuranceresource estimate and the high level quality assurance time estimatebased on a similar project estimate.
 34. The system of claim 32 whereinthe means for developing the high level quality assurance resourceestimate and the high level quality assurance time estimate comprisesmeans for adding resources to a past quality assurance experience toreduce an implementation time.
 35. The system of claim 32 wherein themeans for developing the high level quality assurance resource estimateand the high level quality assurance time estimate comprises means forestimating a number of test cases and means for multiplying theestimated number of test cases by an average time estimated to executeeach of the test cases.
 36. The system of claim 32 wherein the means fordeveloping the high level quality assurance resource estimate and thehigh level quality assurance time estimate further comprises means forusing a past quality assurance project acceptance test plan and data.37. The system of claim 32 further comprising means for confirming thehigh level quality assurance resource estimate and the high levelquality assurance time estimate by reviewing the business analysisdocument, creating one or more statements, and verifying the one or morestatements.
 38. The system of claim 32 further comprising means forrefining the high level quality assurance resource estimate and the highlevel quality assurance time estimate by listing a project by one ormore functions, creating a plurality of statements, verifying thestatements, confirming the high level quality assurance resourceestimate and the high level quality assurance time estimate, andidentifying a plurality of acceptance test characteristics.
 39. Thesystem of claim 38 wherein the acceptance test characteristics include anumber of functions, a number of test cases, a number of remaining testcases, a number of defects, a number of open defects, a responsibleparty and a status.
 40. The system of claim 32 wherein the qualityassurance process is a software development process.
 41. A process ofacceptance test plan processing in a quality assurance processcomprising the steps of: (a) creating an overview describing a projectbeing implemented; (b) developing a plurality of objectives stating aplurality of high level goals and a plurality of strategies required tosuccessfully complete the acceptance test plan process; (c) identifyinga plurality of risks to a schedule for and a quality level of theacceptance test plan process; (d) proposing one or more remedies foreach identified risk; (e) identifying one or more basic testing-relatedissues and support issues required to successfully complete theacceptance test plan process; (f) drafting a description of software andhardware necessary for the acceptance test plan process; (g) identifyingone or more limitations imposed upon the acceptance test plan process;(h) identifying a list of persons necessary to approve an acceptancetest plan of the acceptance test plan process; (i) drafting a glossaryincluding a definition of each technical, business and QA term used inthe acceptance test plan; (j) developing an acceptance test strategy;(k) identifying one or more conditions for execution of the acceptancetest plan; (l) creating a test specification including one or more typesof processing cycles and one or more environmental changes that may berequired during the acceptance of the acceptance test plan; (m)identifying a plurality of test cases to be verified during theexecution of the acceptance test plan; (n) identifying a testingschedule and a scope of testing described in the acceptance test plan;and (o) identifying a framework for handling one or more severe systemproblems that are present at the end of the execution of the acceptancetest plan.
 42. The process of claim 41 wherein the step of drafting thelist of persons comprises a sub-step of identifying a list of personsneeded to approve the acceptance test plan and to review test material,and identifying a list of persons from an information technology groupneeded to approve the acceptance test plan.
 43. The process of claim 41wherein the step of developing an acceptance test strategy comprises asub-step of identifying the one or more environmental changes byproducing a high level description of resources required to execute theacceptance test plan.
 44. The process of claim 41 wherein the step ofdeveloping an acceptance test strategy comprises a sub-step ofdeveloping an acceptance test approach and a scope by identifying one ormore cycles of tests planned for the acceptance test plan andidentifying one or more testing limitations and one or more identifiableranges of the tests.
 45. The process of claim 41 wherein the conditionsfor the execution of the acceptance test plan include identifying atleast one of a plurality of events required to be successfully completedprior to beginning the execution of the acceptance test plan,identifying a plurality of resources required to complete the executionof the acceptance test plan, identifying a plurality of test tools toautomate any part of the acceptance test process, and identifying aplurality of persons and a plurality of corresponding responsibilitiesfor each person during the execution of the acceptance test plan.
 46. Asystem for acceptance test plan processing in a quality assuranceprocess comprising: (a) means for creating an overview describing aproject being implemented; (b) means for developing a pluralityobjectives stating a plurality of high level goals and a plurality ofstrategies required to successfully complete the acceptance test planprocess; (c) means for identifying a plurality of risks to a scheduleand a quality level of the acceptance test plan process; (d) means forproposing one or more remedies for each identified risk; (e) means foridentifying one or more basic testing-related issues and support issuesrequired to successfully complete the acceptance test plan process; (f)means for drafting a description of software and hardware necessary forthe acceptance test plan process; (g) means for identifying one or morelimitations imposed upon the acceptance test plan process; (h) means foridentifying a list of persons necessary to approve an acceptance testplan of the acceptance test plan process; (i) means for drafting aglossary including a definition of each technical, business and qualityassurance term used in the acceptance test plan; (j) means fordeveloping an acceptance test strategy; (k) means for identifying one ormore conditions required for execution of the acceptance test plan; and(l) means for creating a test specification including one or more typesof processing cycles and one or more environmental changes that may berequired during the acceptance test; (m) means for identifying the testcases to be verified during the execution of the acceptance test plan;(n) means for identifying a testing schedule and a scope of testingdescribed in the acceptance test plan; and (o) means for identifying aframework for handling one or more severe system problems that arepresent at the end of the execution of the acceptance test plan.
 47. Thesystem of claim 46 wherein the means for drafting the list of personscomprises means for identifying a list of persons needed to approve theacceptance test plan and to review test material, and means foridentifying a list of persons from an information technology groupneeded to approve the acceptance test plan.
 48. The system of claim 46wherein the means for developing the acceptance test strategy includesmeans for identifying one or more environmental changes by producing ahigh level description of quality assurance resources required toexecute the acceptance test plan.
 49. The system of claim 46 wherein themeans for developing the acceptance test strategy includes means fordeveloping an acceptance test approach and a scope by identifying one ormore cycles of tests planned for the acceptance test and identifying oneor more testing limitations and one or more identifiable ranges of thetests.
 50. The system of claim 46 wherein the conditions for theexecution of the acceptance test plan include at least one of aplurality of events required to be successfully completed prior tobeginning the execution of the acceptance test plan, a plurality of testtools to automate any part of the acceptance test process, andidentification of a plurality of persons and a plurality ofcorresponding responsibilities for each person during the execution ofthe acceptance test plan.
 51. A process of creating a plurality of testscripts for use in a quality assurance system comprising: (a) reviewingan acceptance test plan; (b) performing a function log process toproduce a function log document including a plurality of individual testcases; and (c) performing a test script process to produce a test scriptdocument including a plurality of specific testing instructions for eachof the individual test cases of the function log document.
 52. Theprocess of claim 51 wherein the function log document comprises anidentification of a test case, a function number associated with theidentified test case, a function identifier, an expected result and anindication of whether the function passed the test case.
 53. The processof claim 51 wherein the test script document comprises an identificationof a function/script, a function/script number, a script activity percycle, an expected result and an indication of whether the functionpassed the test script.
 54. The process of claim 51 wherein an input tothe function log process is the acceptance test plan and an output ofthe function log process is the function log document.
 55. The processof claim 54 wherein an input to the test script process is the functionlog document and an output to the test script process is the test scriptdocument.
 56. A system for creating a plurality test scripts in aquality assurance system comprising: (a) means for reviewing anacceptance test plan; (b) means for performing a function log process toproduce a function log document including a plurality of individual testcases; and (c) means for performing a test script process to produce atest script document including a plurality of specific testinginstructions for each of the individual test cases of the function log.57. The system of claim 56 wherein the function log document comprisesan identification of a test case, a function number associated with theidentified test case, a function identifier, an expected result and anindication of whether the function passed the test case.
 58. The systemof claim 56 wherein the test script document comprises an identificationof a function/script, a function/script number, a script activity percycle, an expected result and an indication of whether the functionpassed the test script.
 59. The system of claim 56 wherein an input tothe function log process is the acceptance test plan and an output ofthe function log process is the function log document.
 60. The system ofclaim 56 wherein an input to the test script process is the function logdocument and an output to the test script process is the test scriptdocument.
 61. A process for processing one or more defects found in aquality assurance process comprising the steps of: (a) identifying apotential defect; (b) creating a defect ticket record for the identifieddefect; (c) recording the identified defect on a project defect trackinglog; (d) transmitting the defect ticket record to a developer; (e)receiving the defect ticket record from the developer after thedeveloper processes and corrects the identified defect; (f) retestingthe corrected defect; (g) updating the project defect tracking log andclosing the corrected defect if the retesting is successful; (h)transmitting the defect ticket record to the developer if the retestingis not successful; and (i) placing the defect ticket record in a projectfolder after the closing of the defect ticket record.
 62. The process ofclaim 61 wherein the defect ticket record comprises a projectidentification, a defect number, a priority identification, anidentification of a reporter, a test case number, a function areaidentification, a description of the identified defect, a date ofopening of the defect ticket record, an identification of an applicationassociated with the identified defect, an identification of a correctorand a date of correction of the identified defect, an identification ofa retester and a date of retesting, and an identification of a retesterand a date of closing of the defect ticket record if retesting issuccessful.
 63. A system for processing defects in a quality assuranceprocess comprising: (a) means for identifying a potential defect; (b)means for creating a defect ticket record for the identified defect; (c)means for recording the identified defect on a project defect trackinglog; (d) means for transmitting the defect ticket record to a developer;(e) means for receiving the defect ticket record from the developerafter the developer processes and corrects the identified defect; (f)means for retesting the corrected defect; (g) means for updating theproject defect tracking log and closing the corrected defect if theretesting is successful; (h) means for transmitting the defect ticketrecord to the developer if the retesting is not successful; and (i)means for placing the defect ticket record in a project folder after theclosing of the defect ticket record.
 64. The system of claim 63 whereinthe means for creating the defect ticket record comprises means forrecording a project identification, a defect number, a priorityidentification, an identification of a reporter, a test case number, afunction area identification, a description of the identified defect, adate of opening of the defect ticket record, an identification of anapplication associated with the identified defect, an identification ofa corrector and a date of correction of the identified defect, anidentification of a retester and a date of retesting, and anidentification of a retester and a date of closing of the defect ticketrecord if the retesting is successful.
 65. A process for processing oneor more defects in a quality assurance process comprising the steps of:(a) identifying a potential defect; (b) creating a defect ticket recordfor the identified defect; (c) recording the identified defect on aproject defect tracking log; (d) transmitting the defect ticket recordto a developer area; (e) correcting the identified defect in thedeveloper area if the identified defect needs to be corrected; (f)explaining the identified defect in the developer area if the identifieddefect does not need to be corrected; (g) transmitting the defect ticketrecord to a quality assurance area; (h) retesting the identified defectif defect correction was attempted in the developer area; (i) updatingthe project defect tracking log and closing the defect ticket record ifthe corrected defect passes the retesting; (j) transmitting the defectticket record to the developer area if the corrected defect does notpass the retesting; (k) updating the project defect tracking log andclosing the defect ticket record if defect correction was not attemptedin the developer area; and (l) placing the defect ticket record in aproject folder after the closing of the defect ticket record.
 66. Theprocess of claim 65 wherein the defect ticket record comprises a projectidentification, a defect number, a priority identification, anidentification of a reporter, a test case number, a function areaidentification, a description of the identified defect, a date ofopening of the defect ticket record, an identification of an applicationassociated with the identified defect, an identification of a correctorand a date of correction of the identified defect, an identification ofa retester and a date of retesting, and an identification of a retesterand a date of closing of the defect ticket record if the retesting issuccessful.
 67. A system for processing defects in a quality assuranceprocess comprising: (a) means for identifying a potential defect; (b)means for creating a defect ticket record for the identified defect; (c)means for recording the identified defect on a project defect trackinglog; (d) means for transmitting the defect ticket record to a developerarea; (e) means for correcting the identified defect in the developerarea if the identified defect needs to be corrected; (f) means forexplaining the identified defect in the developer area if the identifieddefect does not need to be corrected; (g) means for transmitting thedefect ticket record to a quality assurance area; (h) means forretesting the identified defect if defect correction was attempted inthe developer area; (i) means for updating the project defect trackinglog and closing the defect ticket record if the corrected defect passesthe retesting; (j) means for transmitting the defect ticket record tothe developer area if the corrected defect does not pass the retesting;and (k) means for placing the defect ticket record in a project folderafter the closing of the defect ticket record.
 68. The system of claim67 wherein the means for creating the defect ticket record comprisesmeans for recording a project identification, a defect number, apriority identification, an identification of a reporter, a test casenumber, a function area identification, a description of the identifieddefect, a date of opening of the defect ticket record, an identificationof an application associated with the identified defect, anidentification of a corrector and a date of correction of the identifieddefect, an identification of a retester and a date of retesting, and anidentification of a retester and a date of closing of the defect ticketrecord if the retesting is successful.